Archive for marca 2016

GIT

00:24 0 Comments A + a -

Kilka dni temu miałem przyjemność poprowadzić w firmie wewnętrzne szkolenie/wstęp do Gita.

BTW, za swój osobisty sukces uważam fakt, że już po pierwszym miesiącu pracy dostałem szansę “oficjalnego” zaprezentowania zajebistości Gita programistom chłostanym dotychczas bezlitośnie przez TFSową kontrolę wersji witkami z doczepionymi haczykami na ryby po osolonych plecach. Efekt był dość prosty do przewidzenia: podobało się.

Poniżej wrzucam swoją listę tematów do poruszenia. Moim zdaniem są to najważniejsze elementy do pokazania w sensownym czasie nieprzekraczającym połowy dnia pracy, gdzie zostaje jeszcze sporo luzu na eksperymentowanie i demonstrowanie na żywo pewnych najczęściej spotykanych scenariuszy. Może ta lista posłuży komuś do wyjścia w swojej firmie z podobną inicjatywą, czyli zaprezentowania Gita szerszemu gronu? Gitersi wszystkich firm, łączmy się;).

Co to jest Git i dlaczego jest lepszy niż TFS:

  • rozproszony system kontroli wersji
  • każdy ma swoje pełne repozytorium
  • diff/log/… – wszystko lokalnie
  • commity – też lokalnie
  • komunikacja z centralnym serwerem (jedna z możliwości podzielenia się kodem z zespołem)
    • pull – pobranie najnowszego kodu
    • push – wysłanie własnych commitów
    • “remotes” – linki do zdalnych repozytorium
  • gałęzie
    • gałąź “główna” – master
    • lokalne gałęzie – całkowita swoboda w poruszaniu się i organizacji pracy
  • żadnych exclusive locks
  • świetny merge
  • śledzi zawartość plików, a nie pliki
    • stąd automatyczne wykrywa np. rename
  • (blog) Git – rozproszony system kontroli wersji (DVCS) – krótkie omówienie i garść linków
  • (blog) W czym Git jest lepszy od TFS?

Komendy do poruszania się po gicie:

  • pull – ściąga kod z centralnego serwera i łączy z naszym
  • push – wysyła nasz kod (lokalne commity) na centralny serwer
  • checkout
    • po podaniu nazwy gałęzi: przełącza working copy między gałęziami
    • z flagą ‘-b’ – tworzy nową gałąź
    • po podaniu nazwy pliku: ściąga plik z podanej wersji (bez podania wersji – ściąga z ostatniego commita -> usuwa “niezacommitowane” zmiany)
  • branch
    • listuje aktualne gałęzie
    • z flagą ‘-d’ – usuwa gałąź o podanej nazwie
  • help: git [command]–help
  • (blog) Git – początek – pierwsze kroki po instalacji gita

Indeks (“staging area”):

  • miejsce między working copy a commitem
  • “cache” zmian, które znajdą się w następnym commicie
  • pozwala na bardzo dokładną kontrolę nad tym co zostanie zacommitowane
  • można dowolnie manipulować zawartością indeksu, np zapisując tam tylko część pliku do commita

Komendy do working copy, indeksu i commitów:

  • add – dodanie zmian do indeksu
    • add -A – dodanie wszystkich zmian do indeksu
    • add -i – interactive add, dokładna kontrola nad tym co zostanie dodane do indeksu
    • add -i -> patch – dodawanie części zmian z danego pliku do indeksu
  • commit – stworzenie commita z aktualnego stanu indeksu
    • pierwsza linijka w commit msg – krótki opis, potem pusta linia, potem ew. dłuższy opis – tip dla narzędzi wyświetlających logi
  • clean – czyszczenie plików ‘untracked’
  • reset – czyszczenie indeksu
    • reset –hard – czyszczenie indeksu i working copy, coś jak “undo pending changes”
  • stash – zachowanie aktualnych zmian na później, poza indeksem i poza commitami (coś jak shelve, tylko lokalnie)

Struktura commitów

  • lokalne commity – lista podzielona na gałęzie
    • każdy commit jednoznacznie identyfikowany SHA1 ID
    • każdy commit można otagować
  • ostatni commit w gałęzi to HEAD
  • merge tworzy “merge commit” będący dzieckiem dwóch commitów
    • można zrobić merge bez tego, ale nie ma sensu w to teraz wnikać
  • można dowolnie nawigować się pomiędzy commitami (znając jego ID, nazwę bądź położenie relatywne do innego znanego commita, np końcówki gałęzi)
    • git checkout master^ – 1 commit przed HEAD master
    • git checkout master~4 – 4 commity przed HEAD master

Modyfikacja historii:

  • commit –amend – modyfikacja ostatniego commita
  • rebase – “nałożenie” jednej gałęzi na drugą gałąź
  • rebase -i – interactive rebase
    • reword
    • edit
    • squash
    • …
  • NIE WOLNO modyfikować historii już wysłanej na serwer (!!!)
    • standardowo git nie pozwoli tego zrobić, jeśli wysyłamy do innego repo gita…
    • … ale nie wiem jak zachowa się TFS
  • (blog) Modyfikacja historii w Gicie

Git-TFS:

  • workflow:
    • [master]
    • git tfs pull – mamy najnowszy kod z repo
    • git checkout -b our-branch-name – tworzymy gałąź do bieżących prac
    • git add/commit… – pracujemy
    • git add/commit… – pracujemy

      git add/commit… – pracujemy

    • git checkout master – powracamy do gałęzi głównej
    • git tfs pull – ściągamy najnowszy kod (w [master]zawsze mamy kod bez swoich modyfikacji)
    • git checkout our-branch-name – wracamy na naszą gałąź
    • git rebase master – “nakładamy” naszą gałąź na najnowszy kod z TFS (ew. radzimy sobie z merge – mi się tutaj jeszcze nie zdarzyło żebym musiał to robić)
    • wysyłamy zmiany do TFS
      • git tfs rcheckin -w [task id]– wypychamy nowe commity z naszej gałęzi do TFSa mówiąc z jakim taskiem ma skojarzyć; commit messages zostaną umieszczone jako komentarz do checkina
        • działanie “pod spodem”: push jednego commita -> pull -> rebase -> …
        • może kilka chwil potrwać
      • git tfs checkintool –build-default-comment
        • łączy wszystkie commity w jeden
    • git checkout master – powracamy do gałęzi głównej
    • git tfs pull – ściągamy do [master]a nasze zmiany (plus ewentualnie inne które wydarzyły się w tym czasie)
    • git branch -d our-branch-name – kasujemy naszą gałąź, nie jest już potrzebna (możemy skasować bo wszystkie zmiany z niej są w masterze, inaczej git by na to nie pozwolił)
  • (blog) git-tfs – lek na prawie całe zło

Narzędzia:

  • git bash (z aliasami gita lub autohotkeys)
  • tortoise git
    • używam do logów i diffów z total commandera
    • dla mnie osobiście najwygodniejsze
  • gitk
    • wbudowany log-viewer
    • pokazuje stan indeksu vs stan working copy
    • dla mnie mimo wszystko żółwik jest wygodniejszy
  • git gui
    • wbudowany ‘okienkowy klient’ do kontaktu z gitem
    • przydaje mi się tylko gdy odpalam raz na jakiś czas żeby zobaczyć czy pora na ‘cleanup’
      • sugeruje uruchomienie git gc jeśli jest taka potrzeba
  • git extensions for visual studio
    • testowałem dawno temu, ale okazało się że tego nie potrzebuję
      • VS jest wystarczająco wolny bez dodatkowych obciążeń
  • git source control provider
    • nie testowałem, ale j/w – nie potrzebuję; poza tym dodaje okna ‘pending changes’ etc… których nie chcę
  • nawigacja po narzędziach – u mnie
    • [win]+1 – total cmd (menu -> l -> enter = view log)
    • [win]+2 – vs
    • [win]+3 – git bash

Wow-factor:

  • git bisect – identyfikacja commita powodującego błąd w systemie, na przestrzeni długiej historii [blog]
  • git cherry-pick – przenoszenie jednego commita pomiędzy gałęziami
  • git reflog – historia WSZYSTKICH operacji

Linki:

.
Subskrybuj: Posty ( Atom )